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Abstract 


This document describes a general and flexible TLV (type-length-value 
structure) for representing time-values, such as an interval ora 
duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/ 


message format. It defines two Message TLVs and two Address Block 
TLVs for representing validity and interval times for MANET routing 
protocols. 
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Introduction 


The generalized packet/message format [RFC5444] specifies a signaling 
format that MANET routing protocols can employ for exchanging 
protocol information. This format presents the ability to express 
and associate attributes to packets, messages, or addresses, by way 
of a general TLV (type-length-value) mechanism. 


This document specifies a general Time TLV structure, which can be 
used by any MANET routing protocol that needs to express either 
single time-values or a set of time-values with each time-value 
associated with a range of hop counts, as provided by the Message 
Header of [RFC5444]. This allows a receiving node to determine a 
single time-value if either it knows its hop count from the 
originator node or the Time TLV specifies a single time-value. 


A time-value is, in this context, not an "absolute point in time", 
but rather an interval or a duration. An instance of a Time TLV can, 
therefore, express an interval or a duration such as "10 seconds". 


This document also specifies two Message TLV Types, which use the TLV 
structure proposed. These TLV Types are INTERVAL_TIME and 
VALIDITY_TIME, specifying, respectively, the maximum time before 
another message of the same type as this message from the same 
originator should be received, and the duration for which the 
information in this message is valid after receipt. Note that, if 
both are present, then the latter will usually be greater than the 
former in order to allow for possible message loss. 


This document also specifies two Address Block TLV Types, which use 
the TLV structure proposed. These TLV Types are INTERVAL_TIME and 
VALIDITY_TIME, defined equivalently to the two Message TLVs with the 
same names. 


1. Motivation and Rationale 


The Time TLV structure, specified in this document, is intended to be 
used as a component in a MANET routing protocol, e.g., to indicate 
the expected spacing between successive transmissions of a given 
Message Type, by including a Time TLV in transmitted messages. 


Some MANET routing protocols may employ very short spacing for some 
messages and very long spacing for others, or may change the message 
transmission rate according to observed behavior. For example, if a 
network is observed at some point in time to exhibit a highly dynamic 
topology, a very short (sub-second) message spacing could be 
appropriate, whereas if the network later is observed to stabilize, 
multi-hour message spacing may become appropriate. Different MANET 
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routing protocols and different deployments of MANET routing 
protocols may have different granularity requirements and bounds on 
shortest and longest spacing between successive message 
transmissions. 


In addition, MANET routing protocol deployments typically use 
bandwidth-limited wireless network interfaces, and therefore prefer 
to trade off computational complexity for a saving in the number of 
bits transmitted. This is practical in this case, because the 
intended usages of Time TLVs, including the specified examples of 
message interval time and information validity time, do not require 
high-precision values of time. 


The Time TLV structure, specified in this document, caters to these 
characteristics by: 


o encoding time-values, such as an interval or a duration, in an 
8-bit field; while 


o allowing these time-values to range from "very small" (e.g., 
1/1024 second) to "very long" (e.g., 45 days); and 


o allowing a MANET routing protocol, or a deployment, to 
parameterize this (e.g., to attain finer granularity at the 
expense of a lower upper bound) through a single parameter, C. 


The parameter C must be the same for all MANET routers in the same 
deployment. 


The TLV mechanism as specified in [RFC5444] allows associating a 
"value" to either a packet, a message, or to addresses. The data 
structure for doing so -- the TLV -- is identical in each of the 
three cases; however, the TLV’s position in a received packet allows 
determining if that TLV is a "Packet TLV" (it appears in the Packet 
Header, before any messages), a "Message TLV" (it appears in the TLV 
Block immediately following a Message Header), or an "Address Block 
TLV" (it appears in the TLV Block immediately following an Address 
Block). 


While TLVs may be structurally identical, that which they express may 
be different. This is determined from the kind (packet, message, or 
Address Block) and type of the TLV. For example, one TLV might 
associate a lifetime to an address, another a content sequence number 
to a message, and another a cryptographic signature to a packet. For 
this reason, [RFC5444] specifies separate registries for Packet TLV 
Types, Message TLV Types, and Address Block TLV Types, and it does 
not specify any structure in the TLV Value field. 
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The TLVs defined in this document express, essentially, that "this 
information will be refreshed within X seconds" and that "this 
information is valid for X seconds after being received", each 
allowing the "X seconds" to be specified as a function of the number 
of hops from the originator of the information. This document 
specifies a general format allowing expressing and encoding this as 
the value field of a TLV. This representation uses a compact (8-bit) 
representation of time, as message size is an issue in many MANETs, 
and the offered precision and range is appropriate for MANET routing 
protocols. 


A TLV of this format may be used for packets, messages, or addresses. 
For example, a proactive MANET routing protocol periodically 
reporting link-state information could include a TLV of this format 
as a Message TLV. This may indicate a different periodicity in 
different scopes (possibly frequently up to a few hops, less 
frequently beyond that) because some messages may be sent with 
limited scope, as specified in [RFC5444]. A reactive MANET routing 
protocol could include a TLV of this format as an Address Block TLV 
for reporting the lifetime of routes to individual addresses. 


In addition to defining the general format as outlined above, this 
document requests IANA assignments for INTERVAL_TIME and 
VALIDITY_TIME TLVs. These IANA assignments are requested in this 
document in order to avoid interdependencies between otherwise 
unrelated MANET protocols and in order to not exhaust the TLV Type 
spaces by having different protocols request types for essentially 
identical data structures. Only Message TLVs and Address Block TLVs 
are requested, as these are those for which a need has been 
demonstrated. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 


Additionally, this document uses terminology from [RFC5444], and 
introduces the following terminology: 


hop count - the number of hops from the message originator to the 
message recipient. This is defined to equal the <msg-hop-count> 
field in the <msg-header> element defined in [RFC5444], if 
present, after it is incremented on reception. If the <msg-hop- 
count> field is not present, or in a Packet TLV, then hop count is 
defined to equal 255. 
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time-value - a time, measured in seconds. 
time-code - an 8-bit field, representing a time-value. 
3. Applicability Statement 


The TLV structure described in this document is applicable whenever a 
single time-value, or a time-value that varies with the number of 
hops from the originator of a message, is required in a protocol 
using the generalized MANET packet/message format [RFC5444]. 


Examples of time-values that may be included in a protocol message 
are: 


o The maximum time interval until the next message of the same type 
is to be generated by the message’s originator node. 


o The validity time of the information with which the time-value is 
associated. 


Either of these may vary with the hop count between the originating 
and receiving nodes, e.g., if messages of the same type are sent with 
different hop limits as defined in [RFC5444]. 


Parts of this document have been generalized from material in the 
proactive MANET routing protocol OLSR (Optimized Link State Routing 
Protocol) [RFC3626]. 

4. Protocol Overview and Functioning 
This document does not specify a protocol nor does it mandate 
specific node or protocol behavior. Rather, it outlines mechanisms 
for encoding time-values using the TLV mechanism of [RFC5444]. 

5. Representing Time 
This document specifies a TLV structure in which time-values are each 
represented in an 8-bit time-code, one or more of which may be used 
in a TLV’s <value> field. Of these 8 bits, the least significant 3 
bits represent the mantissa (a), and the most significant 5 bits 
represent the exponent (b), so that: 


o time-value := (1 + a/8) * 2%b * C 


o time-code :=8 *bta 
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All nodes in the MANET MUST use the same value of the constant C, 
which will be specified in seconds, hence so will be all time-values. 
C MUST be greater than 0 seconds. Note that ascending values of the 
time-code represent ascending time-values; time-values may thus be 
compared by comparison of time-codes. 


An algorithm for computing the time-code representing the smallest 
representable time-value not less than the time-value t is: 


1. find the largest integer b such that t/C >= 2%b; 


2. set a := 8 * (t / (C * 2%b) - 1), rounded up to the nearest 
integer; 
3. if a = 8, then set b := b + 1 and set a := 0; 


4. if 0 <= a <= 7, and 0 <= b <= 31, then the required time-value 
can be represented by the time-code 8 * b + a, otherwise it 
cannot. 


The minimum time-value that can be represented in this manner is C. 
The maximum time-value that can be represented in this manner is 15 * 
2°28 * C, or about 4.0 * 10*9 * C. If, for example, C = 1/1024 
second, then this is about 45 days. 


A protocol using this time representation MUST define the value of C. 
A protocol using this specification MAY specify that the all-bits 
zero time-value (0) represents a time-value of zero and/or that the 
all-bits one time-value (255) represents an indefinitely large time- 
value. 


6. General Time TLV Structure 


The following data structure allows the representation of a single 

time-value, or of a default time-value plus pairs of (time-values, 

hop counts) for when hop-count-dependent time-values are required. 

The time-values are represented as time-codes as defined in 

Section 5. This <time-data> data structure is specified, using the 
regular expression syntax of [RFC5444], by: 


<time-data> = (<time-code><hop-count>) *<time-code> 
where: 


<time-code> is an 8-bit unsigned integer field containing a time- 
code as defined in Section 5. 
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<hop-count> is an 8-bit unsigned integer field specifying a hop 
count from the message originator. 


A <time-data> structure thus consists of an odd number of octets; 
with a repetition factor of n for the (time, hop count) pairs in the 
regular expression syntax, it contains 2n+1 octets. On reception, n 
is determined from the length. 


A <time-data> field may be thus represented by: 


<t_1><d_1><t_2><d_2> ... <t_i><d_i> ... <t_n><d_n><t_default> 
<d_l>, ... <d_n>, if present, MUST be a strictly increasing sequence, 
with <d_n> < 255. Then, at the receiving node’s hop count from the 


originator node, the time-value indicated is that represented by the 
time-code: 


o <t_1l>, if n > 0 and hop count <= <d_1>; 


o <t_itl>, if n > 1 and <d_i> < hop count <= <d_i+1> for some i such 
that 1 <= i < n; 


o <t_default> otherwise, i.e. if n = 0 or hop count > <d_n>. 


If included in a message without a <msg-hop-count> field in its 
Message Header, or in a Packet TLV, then the form of this data 
structure with a single time-code in <time-data> (i.e., n = 0) SHOULD 
be used. 


6.1. Single-Value Time TLVs 


The purpose of a single value Time TLV is to allow a single time- 
value to be determined by a node receiving an entity containing the 
Time TLV, based on its hop count from the entity’s originator. The 
Time TLV may contain information that allows that time-value to be a 
function of the hop count; thus, different receiving nodes may 
determine different time-values. 


A single-value Time TLV may be a Packet TLV, a Message TLV, or an 
Address Block TLV. 


A Time TLV that has the tismultivalue flag cleared (’0’) in its <tlv- 
flags> field, as defined in [RFC5444], contains a single <time-data>, 


as defined above, in its <value> field. For such a Time TLV: 


o The <length> field in the TLV MUST contain the value 2n+1, with n 
being the number of (time-value, hop count) pairs in the Time TLV. 
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o The number of (time-value, hop count) pairs MUST be identified by 
inspecting the <length> field in the TLV. The number of such 
pairs, n, is: 


* n := (<length> - 1) / 2 
This MUST be an integer value. 
6.2. Multi-Value Time TLVs 


The purpose of a multi-value Time TLV is to associate a set of <time- 
data> structures to an identically sized set of addresses, as 
described in [RFC5444]. For each of these <time-data> structures, a 
single time-value can be determined by a node receiving an entity 
containing the Time TLV, based on its hop count from the entity’s 
originator. The Time TLV may contain information that allows that 
time-value to be a function of the hop count, and thus different 
receiving nodes may determine different time-values. 


Multi-value Time TLVs MUST be Address Block TLVs. A multi-value Time 
TLV MUST NOT be a Packet TLV or Message TLV. 


A Time TLV that has the tismultivalue flag set (’1’) in its <tlv- 
flags> field, as defined in [RFC5444], contains a sequence of <time- 
data> structures, as defined above, in its <value> field. For sucha 
Time TLV: 


o The <length> field in the TLV MUST contain the value m * (2n+1), 
with n being the number of (time-value, hop count) pairs in the 
Time TLV, and m being number-values as defined in [RFC5444]. 


o The number of <time-data> structures included in the <value> field 
is equal to number-values as defined in [RFC5444]. 


o The number of (time-value, hop count) pairs in each <time-data> 
structure MUST be the same, and MUST be identified by inspecting 
the <length> field in the TLV and using number-values as defined 
in [RFC5444]. The number of such pairs in each <time-data> 
structure, n, is: 


* n := ((<length> / number-values) - 1) / 2 


This MUST be an integer value. The lists of hop count values MAY 
be different. 
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7. Message TLVs 


Two Message TLVs are defined, for signaling message interval 
(INTERVAL_TIME) and message validity time (VALIDITY_TIME). 


7.1. INTERVAL_TIME TLV 


An INTERVAL_TIME TLV is a Message TLV that defines the maximum time 
before another message of the same type as this message from the same 
originator should be received. This interval time MAY be specified 
to depend on the hop count from the originator. (This is appropriate 
if messages are sent with different hop limits so that receiving 
nodes at greater hop counts have an increased interval time.) 


A message MUST NOT include more than one INTERVAL_TIME TLV. 


An INTERVAL_TIME TLV is an example of a Time TLV specified as in 
Section 5. 


7.2.  VALIDITY_TIME TLV 


A VALIDITY_TIME TLV is a Message TLV that defines the validity time 
of the information carried in the message in which the TLV is 
contained. After this time, the receiving node MUST consider the 
message content to no longer be valid (unless repeated in a later 
message). The validity time of a message MAY be specified to depend 
on the hop count from its originator. (This is appropriate if 
messages are sent with different hop limits so that receiving nodes 
at greater hop counts receive information less frequently and must 
treat is as valid for longer.) 


A message MUST NOT include more than one VALIDITY_TIME TLV. 


A VALIDITY_TIME TLV is an example of a Time TLV specified as in 
Section 5. 


8. Address Block TLVs 
Two Address Block TLVs are defined, for signaling address 
advertisement interval (INTERVAL_TIME) and address validity time 
(VALIDITY_TIME) . 

Bed. INTERVAL TIME TLV 
An INTERVAL_TIME TLV is an Address Block TLV that defines the maximum 
time before this address from the same originator should be received 


again. This interval time MAY be specified to depend on the hop 
count from the originator. (This is appropriate if addresses are 
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contained in messages sent with different hop limits so that 
receiving nodes at greater hop counts have an increased interval 
time.) 


A protocol using this TLV and the same named Message TLV MUST specify 
how to interpret the case when both are present (typically, that the 
former overrides the latter for those addresses that are covered by 
the former). 


An INTERVAL_TIME TLV is an example of a Time TLV specified as in 
Section 5. 


8.2. VALIDITY_TIME TLV 


A VALIDITY_TIME TLV is an Address Block TLV that defines the validity 
time of the addresses to which the TLV is associated. After this 
time, the receiving node MUST consider the addresses to no longer be 
valid (unless these are repeated in a later message). The validity 
time of an address MAY be specified to depend on the hop count from 
its originator. (This is appropriate if addresses are contained in 
messages sent with different hop limits so that receiving nodes at 
greater hop counts receive information less frequently and must treat 
is as valid for longer.) 


A protocol using this TLV and the same named Message TLV MUST specify 
how to interpret the case when both are present (typically, that the 
former overrides the latter for those addresses that are covered by 
the former). 


A VALIDITY_TIME TLV is an example of a Time TLV specified as in 
Section 5. 


9. IANA Considerations 


This specification defines two Message TLV Types, which have been 
allocated from the "Assigned Message TLV Types" repository of 
[RFC5444] as specified in Table 1, and two Address Block TLV Types, 
which have been allocated from the "Assigned Address Block TLV Types" 
repository of [RFC5444] as specified in Table 2. 


IANA has assigned the same numerical value to the Message TLV Type 
and Address Block TLV Type with the same name. 


9.1. Expert Review: Evaluation Guidelines 
For the registries for TLV Type Extensions where an Expert Review is 


required, the designated expert SHOULD take the same general 
recommendations into consideration as are specified by [RFC5444]. 
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Security Considerations 


This document specifies how to add data structures (TLVs) that 
provide timing information to packets and messages specified using 
[RFC5444]. In particular, information validity durations and 
reporting intervals may be added. 


The general security threats that apply are those general to 
[RFC5444] and described therein, problems of integrity and 
confidentiality. With regard to the former, modification of a Time 
TLV can cause information to have an invalid validity time, or 
expected interval time. This may cause incorrect protocol 
performance. Modification or addition of timed information can add 
to a protocol’s workload (especially if a short validity time is 
specified) and storage requirements (especially if a long validity 
time is specified). 


To counter these threats, the security suggestions in [RFC5444], for 
the use of authentication and encryption, are appropriate. 
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